Effective DevOps ―4本柱による持続可能な組織文化の育て方
目次
第Ⅰ部 devopsとは何か
1章 大局を見る
1.1 devops文化のスナップショット
1.2 文化の発展の経緯
1.3 ストーリーの価値
1.4 リンのストーリー
1.5 ジェニファーのストーリー
1.6 devopsをストーリーで説明する
2章 devopsとは何か
2.1 文化のための処方箋
2.2 devopsの方程式
2.2.1 通俗モデルとしての devops
2.2.2 古い見方と新しい見方
2.2.3 devops共同体
3章 devopsの歴史
3.1 オペレーターとしての開発者
3.2 ソフトウェアエンジニアリングの始まり
3.3 プロプライエタリソフトウェアと標準化の登場
3.4 ネットワークの時代
3.5 グローバルなコミュニティの始まり
3.6 アプリケーションとウェブの時代
3.7 ソフトウェア開発手法の発展
3.8 オープンソースソフトウェアとプロプライエタリサービス
3.9 アジャイルインフラストラクチャー
3.10 DevOpsDaysの始まり
3.11 devopsの現状
3.12 まとめ
4章 基本的な用語と概念
4.1 ソフトウェア開発手法
4.1.1 ウォーターフォール
4.1.2 アジャイル
4.1.3 スクラム
4.2 運用手法
4.2.1 ITIL
4.2.2 COBIT
4.3 システム手法
4.3.1 リーン
4.4 開発、リリース、デプロイの諸概念
4.4.1 バージョン管理
4.4.2 テスト駆動開発
4.4.3 アプリケーションのデプロイ
4.4.4 継続的インテグレーション
4.4.5 継続的デリバリー
4.4.6 継続的デプロイ
4.4.7 MVP（実用最小限の製品）
4.5 インフラストラクチャーに関する概念
4.5.1 構成管理
4.5.2 クラウドコンピューティング
4.5.3 インフラストラクチャー自動化
4.5.4 アーティファクト管理
4.5.5 コンテナ
4.6 文化的な概念
4.6.1 レトロスペクティブ
4.6.2 ポストモーテム
4.6.3 非難のない文化
4.6.4 組織的な学習
4.7 まとめ
5章 devopsに対する誤解とアンチパターン
5.1 devopsに対するよくある誤解
5.1.1 devopsに関係があるのは開発者とシステム管理者だけだ
5.1.2 devopsはチームである
5.1.3 devopsは肩書だ
5.1.4 devopsはウェブ系のスタートアップだけの問題だ
5.1.5 devopsには認定資格が必要だ
5.1.6 devopsとは、半分の人員ですべての仕事をすることだ
5.1.7 devopsには「正しい方法」（または「間違った方法」）がある
5.1.8 devopsを取り入れるためには X週間 /Xか月かかる
5.1.9 devopsはツールの問題だ
5.1.10 devopsとは自動化のことだ
5.1.11 devopsは一時的な流行だ
5.2 devopsのアンチパターン
5.2.1 非難文化
5.2.2 サイロ
5.2.3 根本原因分析
5.2.4 ヒューマンエラー
5.3 まとめ
6章 効果的なdevopsのための4本柱
6.1 コラボレーション
6.2 アフィニティ
6.3 ツール
6.4 スケーリング
6.5 まとめ
第Ⅱ部 コラボレーション
7章 コラボレーション:ともに仕事をする個人たち
7.1 Sparkle Corpの週次プランニングミーティングにて
7.2 コラボレーションの定義
7.3 個人の違いと経歴、背景
7.3.1 職業人としての経歴
7.3.2 個人的な経歴
7.3.3 目標
7.3.4 認知スタイル
7.4 競争優位を得るためのチャンス
7.5 メンターシップ
7.5.1 上位者から下位者へのメンタリング
7.5.2 上位者同士のメンタリング
7.5.3 下位者から上位者へのメンタリング
7.5.4 下位者同士のメンタリング
7.6 マインドセット入門
7.6.1 正しいマインドセットを育てる
7.6.2 固定思考
7.6.3 成長思考
7.6.4 個人の成長
7.7 マインドセットと学習する組織
7.8 フィードバックの役割
7.9 評価とランキング
7.9.1 フィードバックの頻度
7.9.2 ランキングシステム
7.9.3 ロックスターやスーパーフロックの問題
7.9.4 チームにとっての社会関係資本の価値
7.10 コミュニケーションと対立の解決スタイル
7.10.1 効果的なコミュニケーション
7.10.2 コミュニケーションの形
7.10.3 コミュニケーションのコンテキストと権力関係
7.11 共感と信頼
7.11.1 共感を育てる
7.11.2 信頼を育てる
7.12 人材配置と人事管理
7.12.1 勤務時間と健康
7.12.2 ワークライフバランス
7.12.3 チームの規模が与える影響
7.13 Sparkle Corpの効果的なコラボレーション
7.14 まとめ
8章 コラボレーション:誤解と問題解決
8.1 コラボレーションの誤解
8.1.1 古くからのシステム管理者に新しい手法は教えられない
8.1.2 急成長したいときにはロックスターを採用しなければいけない
8.1.3 多様性に満ちたチームは効果的にコラボレーションできない
8.2 コラボレーションの問題解決
8.2.1 チームの誰かが持ち分をこなせていない
8.2.2 社員を辞めさせるかどうかを決めなければいけない
8.2.3 私は働きすぎだ、ストレスが溜まっている、燃え尽きた
8.2.4 チームのなかに軽く見られていると感じている人がいる
8.2.5 コミュニケーションが不十分な人がいる
8.2.6 社員（または候補者）に技術的には優れているけれども不愉快な人間がいる
8.2.7 現在のチーム /組織にいる限り自分のキャリアを先に進められる気がしない
8.2.8 （もう）誰も私の言うことを聞いてくれない
8.2.9 組織再編や人員整理を行ったばかりだ
第Ⅲ部 アフィニティ
9章 アフィニティ:個人からチームへ
9.1 Sparkle Corpの開発デモの日
9.2 人のネットワーク
9.3 チームはどのように作られるか
9.3.1 チームが行う仕事
9.3.2 アフィニティの定義
9.3.3 チーム内の個人間の結び付き
9.3.4 チームの文化
9.3.5 チームの団結力
9.3.6 多様性
9.3.7 多様性のメリット
9.3.8 多様性とインターセクショナリティの軸
9.3.9 採用時に考慮すべきこと
9.3.10 開放的な環境の維持
9.4 チームと組織構造
9.5 チーム間で共通な地盤を見つける
9.5.1 競争から協調へ
9.5.2 チームの共感を築く
9.5.3 チームのコミュニケーションの改善
9.6 ケーススタディー：米国特許商標庁
9.6.1 背景と方向性
9.6.2 コラボレーションとアフィニティの奨励
9.6.3 複数の視点のバランスを取る
9.7 アフィニティ向上の効果
9.7.1 サイクルタイムの短縮
9.7.2 コミュニケーションの障害の除去
9.7.3 信頼
9.7.4 イノベーション
9.8 アフィニティのために必要なもの
9.8.1 遊び
9.8.2 明示的な目標と価値観
9.8.3 スペース
9.8.4 コラボレーションと協力
9.9 アフィニティの計測
9.9.1 社員のスキルと評価
9.9.2 チーム間の交渉
9.9.3 コミュニティへの返礼
9.10 Sparkle Corpの Devと Opsのアフィニティ
9.11 まとめ
10章 アフィニティ:誤解と問題解決
10.1 アフィニティの誤解
10.1.1 運用エンジニアは企業にとって開発者ほど役に立たない
10.1.2 外部と共有しすぎると競争優位が弱まる
10.2 アフィニティの問題解決
10.2.1 ひとりまたは複数の個人がグループフローを妨害する
10.2.2 あるチームが別のチームの仕事を止めてしまう
10.2.3 一部のチームが評価されていないと感じる
10.2.4 互いに相手を信頼していないように見える
10.2.5 仕事の技術的な側面ばかり考えていて人間関係について考えていない
10.2.6 共同作業をしているチームが本当の意味で共同作業できるように見えない
10.2.7 過去の個人間の対立が現在のチーム間の対立の原因になっている
10.2.8 チーム Xがサイロに閉じこもりたがっているように見える
10.2.9 devopsの些細な過ちを強く非難する人がいる
第Ⅳ部 ツール
11章 ツール :エコシステムの概要
11.1 ソフトウェア開発
11.1.1 ローカル開発環境
11.1.2 バージョン管理
11.1.3 アーティファクト管理
11.2 自動化
11.2.1 サーバーのインストール
11.2.2 インフラストラクチャーの自動化
11.2.3 システムのプロビジョニング
11.2.4 テストとビルドの自動化
11.3 モニタリング
11.3.1 メトリクス
11.3.2 ロギング
11.3.3 アラート
11.3.4 イベント
11.4 エコシステムの発展
11.5 まとめ
12章 ツール:文化を加速させるもの
12.1 人間にとってのツールの意味
12.2 ツールとは何か
12.3 本当の問題に対応する適切なツール
12.4 オープンソースとの距離
12.5 ツールの標準化
12.6 一貫性のあるツール分析プロセス
12.7 標準化に対する例外
12.8 ツールの意味
12.8.1 ツールではなくプロセスの失敗
12.8.2 ツール選択におけるコンウェイの法則
12.9 ツールが文化に与える影響
12.9.1 コミュニケーションに影響を与えるツール
12.9.2 さまざまな行動に影響を与えるツール
12.10 ツールの選定
12.10.1 製品の開発状況
12.10.2 コミュニティの健全性
12.10.3 内部でのカスタマイズの可能性
12.10.4 実例 : バージョン管理システムの比較
12.10.5 実例 : インフラストラクチャーの構成の自動化
12.11 ツールエコシステムの検証
12.12 ツールの削減
12.12.1 改善 : 計画立案と変化の測定
12.13 ケーススタディー
12.14 DramaFeverの場合
12.14.1 既存技術の影響
12.14.2 新しい技術からの継続的な影響
12.14.3 アフィニティがプラクティスの浸透を促進する
12.14.4 DramaFeverのツール選択
12.15 Etsyの場合
12.15.1 明示的な文化と暗黙的な文化
12.15.2 思いやりの文化
12.15.3 非難のない文化
12.15.4 リモートフレンドリー
12.15.5 ツールによって取り組みを確かなものにする
12.15.6 買うか作るか
12.15.7 自動化についての考え方
12.15.8 成功の測定
12.16 モチベーションと意思決定の難しさ
12.17 Sparkle Corpの効果的なツール利用
12.18 まとめ
13章 ツール:誤解と問題解決
13.1 ツールの誤解
13.1.1 技術 Xから、他社にあわせて技術 Yに移行しなければいけない
13.1.2 技術 Xを使っているので、うちは devopsを実践している
13.1.3 間違ったツールを選ばないように注意しなければいけない
13.1.4 devopsツール全部入りセットや devops-as-a-serviceを買ってくればよい
13.2 ツールの問題解決
13.2.1 技術Xのベストプラクティスを見つけようと努力している
13.2.2 ひとつのツールにする合意が得られない
13.2.3 技術 Xの採用（または廃止）を決めたが、社員がそれに抵抗している
第Ｖ部 スケーリング
14章 スケーリング:変曲点
14.1 スケーリングの理解
14.2 大企業の devopsについて考えるべきこと
14.2.1 devopsによる組織の戦略的拡大 /縮小
14.2.2 意識的なスケーリングのために考えるべきこと
14.2.3 スケーリングのための準備
14.3 組織の構造
14.3.1 地域性
14.4 チームの柔軟性
14.5 組織のライフサイクル
14.5.1 吸血鬼プロジェクトやゾンビプロジェクトの整理
14.5.2 リリースサイクルの影響
14.6 複雑さと改革
14.7 チームのスケーリング
14.7.1 チームの成長 : スケーリングとしての採用
14.7.2 社員の定着
14.8 ケーススタディー：チームの成長とスケーリング
14.8.1 運用チームの構築と育成
14.8.2 「英雄文化」の問題点
14.8.3 求人票と採用活動の問題点
14.8.4 個人とチームの育成
14.8.5 チームメンバーの育成と成長
14.9 チームのスケーリングと成長戦略
14.9.1 チームを小さく柔軟なものに保つ
14.9.2 コラボレーションを育てる
14.9.3 対立のマネジメント
14.10 組織のスケーリング
14.10.1 中央集権チームと臨時チーム
14.10.2 リーダーシップの構築
14.11 ケーススタディー：政府デジタルサービス gov.uk
14.11.1 明示的な文化
14.11.2 計画立案
14.11.3 抱えている難問
14.11.4 アフィニティの構築
14.12 ケーススタディー：Target
14.13 Targetの分析
14.13.1 望ましい結果から始める
14.13.2 大企業のなかでのアフィニティ
14.13.3 大企業のツールと技術
14.13.4 大企業における知識の共有
14.14 まとめ
15章 スケーリング:誤解と問題解決
15.1 スケーリングの誤解
15.1.1 一部のチームは共同作業できない
15.1.2 改革を始めるためには経営陣の全面的な支持が必要だ
15.1.3 すぐには採用の予算が得られないので devopsを始められない
15.2 スケーリングのトラブルシューティング
15.2.1 上が Xを続けることを主張し続け、devopsの価値を認めない
15.2.2 チームが忙しすぎる
15.2.3 よい判断が下せていない
15.2.4 ほしい人材を引きつけることができない
15.2.5 組織変更や人員削減のために士気が下がっている
15.2.6 Xのために独立したチームが必要かどうかわからない
第Ⅵ部 devops文化への架け橋
16章 devopsの4本柱を使って架け橋をつくる
16.1 ストーリーの重要性
16.1.1 明示的なストーリーと暗黙のストーリー
16.2 devopsの理論と現実
16.2.1 現実のケーススタディー：実践を示すストーリー
16.2.2 ストーリーから学ぶこと
16.2.3 ストーリーで結び付きを作る
16.3 まとめ
17章 devops文化への架け橋:ストーリーから学ぶ
17.1 ストーリーが文化について教えてくれること
17.1.1 価値観
17.1.2 禁止事項
17.1.3 神話
17.1.4 儀式
17.1.5 アイデアと知識
17.2 組織の壁を越えた交流
17.2.1 カンファレンスと出張
17.2.2 コミュニティのその他のイベント
17.2.3 エンジニア交換
17.3 組織の壁を越えたアフィニティ
17.3.1 固定思考を避ける
17.3.2 小さな変更から始める
17.4 まとめ
18章 devops文化への架け橋:人と人のつながりを育てる
18.1 仕事をめぐる個々のストーリーとナラティブ
18.1.1 テイラー主義と個人のストーリーの価値
18.1.2 大切にされる人
18.1.3 リモート勤務
18.1.4 退職の形
18.2 文化的負債
18.3 システムの健全性
18.3.1 病んだシステムの分析
18.3.2 健全なシステムの構築
18.3.3 組織の健康と個人の健康
18.3.4 健全な文化と不健全な文化の見分け方
18.4 まとめ
19章 まとめ
19.1 次のステップ
19.2 効果的な devopsを生み出すために
20章 さらに深く学習するために
20.1 devopsとは何か
20.2 コラボレーション : ともに仕事をする個人たち
20.3 アフィニティ : 個人からチームへ
20.4 ツール : 文化を加速させるもの
20.5 スケーリング : 変曲点
20.6 devops文化への架け橋
20.7 お薦めのカンファレンスとミートアップ
20.8 お薦めの Podcast
P.10
私にとって、devopsの価値は「devがXを行いopsがYを行う・つまりdevとopsは対立する」という呪文を唱えることではない
devopsとは何か P13.
devopsは文化運動
仕事に対する個人の考え方を考え、仕事の多様性を尊重し、ビジネスが価値を実現するスピードを加速させる意識的なプロセスを支援し、社会的および技術的変化の効果を計測しようとする
devopsは思考の方法であり、仕事の方法
個人と組織が持続可能な作業習慣を生み出し、維持していくことを可能とするためのもの
devopsは文化的なフレームワーク
ストーリーを共有し、共感を育み、個人とチームが効果的かつ永続的に力を出せるようにする
古い見方「ヒューマンエラーはトラブルの原因」
新しい見方「ヒューマンエラーはシステムの深いところにある問題の兆候」
ヒューマンエラーは個人的なものではなく、構造的なもの
meganii.icon新しい見方を理解して取り入れることが大切
P.15 devops共同体
P.19 ソフトウェアの課題
成功の定義とその測定方法
大きな投資を必要としながら、実現可能性が不透明な複雑なシステムの構築
納期と仕様を満たすシステムの構築
特定の製品を作る業者に対する経済的圧力の実行
P.22 プロプライエタリ（独占所有）
歴史
P.27
文化とプロセスを重視すると、反復が尊ばれ、なぜどのように仕事をするかを改善することが重視されるようになる
わたしたちの重点が「何」から「なぜ」に移ると、私たちの仕事が持つ意味をその目的を確立する自由と信頼が与えられる
仕事に夢中になれば特定の成果を達成することに集中しなくても、結果を大きく変えられる
人は幸せで生産的になり、人類の次の飛躍を生み出せる
P.31 devopsは単なるアジャイル？
devopsはアジャイルの原則を取り入れて、それを発展させたもの
開発プロセスだけでなく組織全体が適用の対象
５章 devopsに対するよくある誤解
5.1.6 devopsとは、半分の人員ですべての仕事をすることだ
devopsは、企業で必要なエンジニアの数を半分にしてコストを節約するわけではない
devopsとは、サービス障害の回数と時間を削減したり、開発にかかる時間を短縮したり、個人とチームの力を底上げしたりして、仕事の品質と効率を上げるための手段
5.1.10 devopsとは自動化のことだ
自動化して節約できる時間よりも自動化のために使う時間の方が多ければ、それは時間の使い方がよくなったとは言えない
この図を探して節約できる時間を調べるために使った時間を忘れてはいけない。それから、時間を費やすことについて説明したこのメモを読むのに使った時間と、どちらに意味があるかを考えるために使った時間もだ。そして、今のこの時間を含め、すべての秒数があなたの人生全体の一部であることを決して忘れてはいけない。
システムが複雑化し、共有サービスのために組織の相互依存が進むと、自動化はとても重要になる
しかし、相互のコンテキストの共有や人のニーズに対する配慮がなければ、自動化は未知のリスクを増やすことにもなる
自動化は仕事を早くするかもしれない
いちばん大きな効果を生み出すためには、透明性やコラボレーションの水準をあげて理解を深める必要がある
5.2.2 サイロ
部門や組織のサイロとは、同じ企業の他のチームと知識を共有する気がないチームの空気を表す
サイロ化されたチームでは、目的や責任を共有せず、それぞれバラバラの役割を重視する
6章 効果的なdevopsのための4本柱
devopsは人間の問題であり、すべての組織がその中の人たちにとって固有のdevops文化を持つことを意味する
すべての組織に共通なひとつの「正しい」devopsの実践方法はない
しかし、devopsを取り入れようとしているチームや組織が時間とリソースを割かなければいけない共通のテーマが4つある
効果的なdevopsのための4本柱
ツール
スケーリング
個人同士の協力関係を育てて維持するのに加えて、組織のチームや部門や業界全体でも関係の強さが必要となる
アフィニティとはチーム間の関係を構築し、組織の共通目標を念頭に置いて個々のチーム目標の違いを乗り越え、共感を育て、他のチームの人たちからも学習するプロセスである
アフィニティは企業や組織にも応用できる
P.65
転職できるぐらいに人を訓練し、転職したいと思わないくらいに厚遇せよ リチャード・ブランソン
meganii.icon なるほどなぁと思った
7章 コラボレーション：共に仕事をする個人たち
7.6 マインドセット入門（P.66）
キャロル・S・ドウェック博士「Carol Dweck, Mindset: The New Psychology of Success」
能力は生まれながらのもので固定
人は生まれながらにして、何かについて得意か不得意であり、その状態は変わらない
と考えている
マインドセットは人の仕事のしかた、難題への取り組み方、失敗への対処方法に大きな影響を与える
See also 「情熱を探そう」というアドバイスはもうやめよう
P.68
7.6.4.3 自分の得意なことを知り、それを伸ばす
自分が仕事で示した実力と成果を正確に測れることは重要
外部システムがなくても、また外部システムとは無関係に、自分自身にフィードバックを与えられるようにならなければいけない
自分自身を率直に評価し、自分の評価メカニズムに満足できれば、望む方向に向かってキャリアを進めていくことができる
P.69
私とは私と環境の合作である。 ホセ・オルテガ・イ・ガセット
オルテガの仮説
平均的で平凡な科学者が科学の進歩に大きく貢献する
=> 平均的な科学者が技術の進歩に大きく貢献する
meganii.icon nanoyaさんのプログラマのスキルの正規分布を思い出した。Rebuild.fmだったのかな
P.74
知性と技術力そのものだけでは、決して最良のチームはうまれなかった
最良のチームは、社会的感受性が高く、みんなが均等に発言し、女性が多く含まれているチーム
meganii.iconm.o.
誰もやりたがらないこの部分に適性があれば、今後もうまくやっていけるのかもしれない
8章 コラボレーション：誤解と問題解決
8.1.1 古くからのシステム管理者に新しい手法は教えられない
新しいスキルが学べないなどということは決してない
新しいテクニックや技術であれ、組織内の他の人に共感したりメンターになったりするような「ソフトスキル」であれ変わらない
ただし、新しいスキルを学ぶためには時間と労力が必要なことは頭に入れておくこと
自分のスキルセットがまもなく賞味期限切れになるのではないかと不安になっている人もいる
新しいクラウドベースの技術やコンテナが普及しても、幅広いスキルセットを持つ人を雇用主は探している
ポイントはぴったりと合うチームやポジションを見つけること
meganii.iconm.o.
コミュニケーションは人と組織の問題
優れたリーダーは、チームとしての価値を上げていく
自分にもなれるのだろうか
9章 アフィニティ：個人からチームへ
9.4 チームと組織構造
9.5 競争から協調へ
エリノア・オストロムは、コモンズのシナリオで協力のための取り組みを成功させるために重要な7つの要素を特定している
協力を成功させるために必要な要素
集団全体の成因をコントロールする手段
社会ネットワーク
参加するすべての人の行動の観察可能性
個人に対する段階的な制裁
過度に変化が激しくないリソース
制裁行動を導入すると、協力の系全体に大きな効果がある と指摘する
最良の瞬間は普通、こんなんではあるが価値のある何かを達成しようとする自発的努力の過程で、身体と精神を限界にまで働かせ切っているときに生じる。このように最適体験は我々が生じさせるものである。 ミハイ・チクセントミハイ
社会理論家 ミハイ・チクセントミハイが提唱
ある活動に従事している個人が、充実し満足した状態で完全に活動に没頭しているときの個人の精神状態をフローだとしている
フローを区別する6つの要素
今に対する強烈な集中
行動と意識の融合
自己に対する意識の欠如
個人による状況の支配または代理
主観的な時間経験の変化
報酬の内在
meganii.icon主観的な時間経験の変化は大いに頷ける。最近なかなかその状態に達せない
個人レベルのフロー
準備や練習を必要とする活動や創造的な能力を必要とする活動に完全に没頭していると感じる意識状態
チーム内のフォロー
例えば、オーケストラ
14章 スケーリング：変曲点
14.7.1.1 下請けの利用
考えるべき重要な点
予算表の数字の上では節約できているかもしれない
個人やチームの間での協調と協力、アフィニティが失われる分、かえってコストが上がる
一部のチームや部門をアウトソーシングしつつ、その他のチームや部門を内部に残すと、直接的にも間接的にも組織内に対立や矛盾を産む大きな要因になる
【パターン1】アウトソーシングによって職種別のサイロが生まれる
現象
知識や情報を抱え込み、責任を他のグループに押し付けようとする
あるグループがアウトソーシングされると、そのグループは「アウトサイダー」になってしまう
内部に残った人たちは、そのグループと情報を共有したり、そのグループを仲間の輪の中に入れたりすることを躊躇する
対処
内部のチームとアウトソーシングのチームの間で、双方向のコミュニケーション経路を明確に確保すること
共通のコミュニケーション手段（それぞれのチームを繋ぐグループチャット、メールリングリストなど）を確保したり、定期的な状況報告を奨励したりすれば、情報の共有を続ける上で役に夏
【パターン2】アウトソーシングされたチームの立場が「下」になる
現象
職場の社会構造の中で、アウトソーシングされたチームは、公式にも非公式にも内部のチームよりも低い階層にいると感じることが多い
対処
全社的に、チームの表彰式などの機会にアウトソーシングのチームを呼ぶ
大切にされていて、グループの一員になっているように感じる人たちは、仕事に大きなモチベーションを持つことが多い
個人やチームのレベルでは、アウトソーシングの従業員を軽く扱うような個人がいないか目を光らせ、そのような行動を許さないこと
上記のことに力を注げば、アウトソーシングのチームとの間で協調的かつ協力的な関係を保つことができる
m.o. meganii.icon
耳が痛い章
アウトソーシングを活用する場面も多いが、コミュニケーションの断絶にならないように気をつけねばならない
20章 さらに深く学習するために
20.3 アフィニティ：個人からチームへ
所感
devopsには絶対的な教義があるわけではない。それは組織での文化であり、働くときの考え方のあり方だと捉えた。
なので、単にツールだけを入れてもうまく定着することはない
人と人とのコラボレーションやコミュニケーションの重要性が大きな部分を占めている
結局、個人ではなく、チームおよび組織が協働する際の問題に終始する
バックグラウンド、今の立場、スキルが様々な人間が、共に仕事（コラボレーション）をする際には、コミュニケーションが欠かせない。
人という個体の
人の認知メカニズムを理解しつつ、仕事に生かしていく
データビジュアライゼーションは、人の認知神経学をベースにハックしていく
devops、組織のリファクタリングは、人の認知メカニズムを理解した上で、組織をハックしていく